A storage system is a processing system adapted to store and retrieve information/data on storage devices (such as disks). The storage system includes a storage operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on the storage devices. Each file may comprise a set of data blocks, whereas each directory may be implemented as a specially-formatted file in which information about other files and directories are stored. A storage system may be referred to herein as a “node.”
The storage operating system generally refers to the computer-executable code operable on a storage system that manages data access and access requests (read or write requests requiring input/output operations) and may implement file system semantics in implementations involving storage systems. In this sense, the Data ONTAP® storage operating system, available from NetApp, Inc. of Sunnyvale, Calif., which implements a Write Anywhere File Layout (WAFL®) file system, is an example of such a storage operating system implemented as a microkernel within an overall protocol stack and associated storage. The storage operating system can also be implemented as an application program operating over a general-purpose operating system, such as UNIX® or Windows®, or as a general-purpose operating system with configurable functionality, which is configured for storage applications as described herein.
A storage system may be configured to allow server systems to access its contents, for example, to read or write data to the storage system. A server system may execute an application that “connects” to the storage system over a computer network, such as a shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. The application executing on the server system may send an access request (read or write request) to the storage system for accessing particular data stored on the storage system.
Currently, a plurality of storage systems may be interconnected as a cluster to provide high availability of data services to the server systems. The nodes of the cluster storage system may be configured to communicate with one another to act collectively to increase performance or to offset any single node failure within the cluster. Each node in the cluster may have a predetermined failover “partner” node. When a node failure occurs (where the failed node is no longer capable of processing access requests), the partner node of the failed node may “takeover” the data services of the failed node. In doing so, access requests sent to the failed node may be re-directed to the partner node for processing. In particular, a cluster may provide data-access service to servers by providing access to shared storage (comprising a set of storage devices). Typically, servers will connect with a node of the cluster for data-access sessions with the node.
The shared storage may comprise a plurality of interrelated storage objects (e.g., aggregates, volumes, files, etc.). For example, the shared storage may comprise a plurality of aggregates, where each aggregate may be configured to contain one or more volumes. The volumes may be configured to store content of other storage objects, such as files and logical units, served by the cluster in response to multi-protocol data access requests. Each node of a cluster may “own” an assigned set of volumes within the shared storage, whereby only the assigned node services data for the assigned volumes during normal operating conditions (when no node has failed). However, upon failure of a node, “ownership” of the volumes of the failed node may be transferred to the partner node (so that serving of data for the volumes of the failed node may be taken over by the partner node). As such, a cluster may be configured such that a partner node may takeover the work load of a failed node where the partner node assumes the tasks of processing and handling any data access requests normally processed by the failed primary node.
A storage system's storage is typically implemented as one or more storage volumes that comprise physical storage devices, defining an overall logical arrangement of storage space. Available storage system implementations can serve a large number of discrete volumes. When a storage system “owns” a volume, it is loaded to the storage system by copying the “volume information” into the storage system's memory. Once a volume has been loaded in memory, the volume may be accessed by one or more servers, applications, devices, and the like, that are permitted to access its contents and navigate its namespace.
For each volume loaded into storage system memory, volume information may comprise a volume head, inode head, and inodes of the volume. The volume head may comprise volume metadata describing the volume. The inode head may comprise a list of inodes (list of inode pointers) of the volume that is used to locate (point to) the inodes of the volume. As known in the art, a file system implemented on the storage system may use a plurality of inodes, each inode representing a file in the file system. An inode may comprise a data structure comprising file metadata, pointers to other indirect blocks or data blocks, and data blocks (containing the actual data of the file).
In some situations, after a volume has been loaded into storage system memory, the volume may need to be removed (invalidated) from memory, typically during an ownership transfer of the volume to another storage system. For example, node A may take ownership of the volumes of failed node B and load the volume information for the volumes into memory. After node B is repaired and comes back online, ownership of the volumes need to be transferred back to node B from node A through a “giveback procedure” so that node B can begin serving data for the volumes. Since node A no longer services data for the volumes, the volume information for the volumes stored in the memory of node A may be removed (invalidated) to free up memory space. Typically, node B can begin serving data for the volumes only after the giveback procedure is completed, but the volume information from the memory of node A must be removed for the giveback procedure to be completed. As such, the procedures for removing the volume information from the memory of node A is time critical as node B cannot begin serving data for the volumes (bring the volumes online) until after completion.
Typically, removing the volume information from memory involves a “walk-through” of the inodes of the volume. During the walk-through procedure, all inodes (and data blocks) of the volume that are currently stored in memory are each located and removed (invalidated). Previously, the memory size of a node was relatively small so that only a small number of the inodes of a volume may be stored in memory at any given time. Due to reduced costs, however, the storage size of storage system memories are increasingly becoming larger so that a larger number of inodes of a volume may be stored in memory at any given time. Thus, the procedures for removing the volume information from memory are increasingly taking longer, which increases the time that the volume is offline and data cannot be accessed from the volume. As such, there is a need for a more efficient system and method for removing volume information from storage system memory.